SYSTEM AND METHOD FOR DEPLOYING A SOFTWARE BUILD FROM A 
PLURALITY OF SOFTWARE BUILDS TO A TARGET COMPUTER 

FIELD OF THE INVENTION 
5 The present invention relates to computer software, and in particular, to deploying 

multiple builds of a computer software application to a target computer. 

BACKGROUND OF THE INVENTION 
In order to achieve broad customer acceptance for a computer software application, 
software providers must make their software applications available in a variety of 

10 configurations. These software applications may be configured according to a variety of 
factors, including spoken languages, computer hardware systems, single and multi-user 
systems, enterprise systems, and home/professional systems, to name just a few. Operating 
systems are excellent examples of software applications which are available in a wide variety 
of configurations. For example, configurations of Microsoft Corporation's Windows 

15 operating system are currently available in English, French, Spanish, and German, to name 
just as few, as well as student, home, and professional editions, and small office and 
enterprise versions. Each specific configuration is generally referred to as a build of the 
software application, or more simply a build, because the application must be particularly 
buih, i.e., compiled, assembled, linked, etc., to create a particular configuration. 

20 For a single user, obtaining a particular software build, and installing the build on the 

user's computer, is a relatively straightforward task. However, in other situations, deploying 
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the build to a target computer can be quite challenging. For example, multinational 
enterprises may require a variety of different builds of the same software application within 
the enterprise. Some enterprise users may require advanced tools that are part of a 
professional build, while others may need only the basics. Still further, some of the offices 
5 in the enterprise may require an English build, while other offices need other languages, such 
as a French build. Clearly, for these types of enterprises, centralizing the distribution, or 
deployment, of a standard software application can be complex and challenging. More often, 
there is no centralized control. Instead, information technology (IT) personnel in each office 
operate semi-autonomously. 

10 Hardware vendors are also faced with the challenge of deploying multiple builds of 

the same software application. For example, hardware vendors typically install an operating 
system on each system that is sold. In order to sell their computer systems to more than one 
class of user, e.g. home users and business users, the hardware vendor must be adaptable, 
able to install a particular operating system build according to a user's request. However, 

15 deploying the particular operating system build must be done efficiently in order to be 
delivered profitably. Of course, hardware vendors also commonly install numerous other 
software applications on a new system, many of which are available in a variety of 
configurations/builds, and must be deployed according to the particular operating system 
build installed on the new system. Clearly, hardware vendors would benefit from a system 

20 and method for deploying multiple software application builds onto a target computer. 

Software providers, those who develop software applications in multiple 
configurations, would also benefit from a system and method for deploying multiple 
software application builds onto a target computer. For example, the software provider's 
quality assurance personnel, i.e., testers, are charged with testing all of a software 

25 application's builds. This often requires that testers install one build, run their battery of tests 
against that build, analyze the results, uninstall the build, and then repeat the process with 
another build. Clearly, efficiently managing the installation/deployment of the builds onto a 
tester's computer would reduce the amount of time involved with installing each build, and 
increase the amount of time that the tester could focus on quality assurance. 
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What is needed is a system and method capable of deploying multiple software 
application builds to a target computer. The present invention addresses these needs, and 
others, found in the prior art. 

SUMMARY OF THE INVENTION 
5 In accordance with aspects of the present invention, a system is provided for 

deploying a software build of a plurality of software builds onto a target computer. The 
system includes a build master that, in response to a request fi-om the target computer for the 
software build, identifies a build server that stores the software build. The build master 
returns request data to the target computer, including information identifying the build server 
10 storing the software build. The system also includes a plurality of build servers, each build 
server storing at least one of the plurality of software builds. A build server, upon receiving 
a request for the software build stored on the build server, returns the build to the target 
computer. 

In accordance with ftirther aspects of the present invention, a method for deploying a 
15 software build from a plurality of software builds to a target computer is provided. A first 
request for the software build is submitted from the target computer to the build master. In 
response to the first request, the build master identifies a build server that stores the software 
build. The build master generates request data, including information identifying the build 
server storing the software build. The request data is returned to the target computer. The 
20 target computer submits the request with the request data to the build server identified in the 
request data. In response, the build server returns the software build to the target computer. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The foregoing aspects and many of the attendant advantages of this invention will 
become more readily appreciated as the same become better understood by reference to the 
25 following detailed description, when taken in conjunction with the accompanying drawings, 
wherein: 

FIGURE 1 is a block diagram illustrating an exemplary computer system suitable for 
implementing aspects of the present invention; 
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FIGURE 2 is a block diagram illustrating components of an exemplary networked 
environment for implementing aspects of the present invention; 

FIGURE 3 is a block diagram illustrating an exemplary exchange of information 
between a target computer and components of the present invention for deploying multiple 
5 software application builds to the target computer; 

FIGURE 4 is a block diagram illustrating components of an alternatively configured 
environment, and the exchange of information between a target computer and components in 
an altematively configured environment for deploying multiple software application builds to 
the target computer; 

10 FIGURE 5 is a flow diagram illustrating an exemplary method for deploying multiple 

software application builds to a target computer in accordance with the present invention; 
and 

FIGURES 6A and 6B are a flow diagram illustrating an altemative exemplary 
method for deploying multiple software application builds to the target computer using a 
15 local server/network configured environment. 

DETAILED DESCRIPTION 
FIGURE 1 and the following discussion are intended to provide a brief, general 
description of a computing system suitable for implementing various features of the 
invention. While the computing system will be described in the general context of a personal 
20 computer usable as a stand-alone computer, or in a distributed computing environment where 
complementary tasks are performed by remote computing devices linked together through a 
communication network, those skilled in the art will appreciate that the invention may be 
practiced with many other computer system configurations, including multiprocessor 
systems, minicomputers, mainframe computers, and the like. In addition to the more 
25 conventional computer systems described above, those skilled in the art will recognize that 
the invention may be practiced on other computing devices including laptop computers, 
tablet computers, and the like. 

While aspects of the invention may be described in terms of application programs 
that run on an operating system in conjunction with a personal computer, those skilled in the 
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art will recognize that those aspects also may be implemented in combination with other 
program modules. Generally, program modules include routines, programs, components, 
data structures, etc., that perform particular tasks or implement particular abstract data types. 
With reference to FIGURE 1, an exemplary system for implementing aspects of the 
5 invention includes a conventional personal computer 102, including a processing unit 104, a 
system memory 106, and a system bus 108 that couples the system memory to the processing 
unit 104. The system memory 106 includes read-only memory (ROM) 110 and random- 
access memory (RAM) 112. A basic input/output system (BIOS) 1 14, containing the basic 
routines that help to transfer information between elements within the personal 

10 computer 102, such as during startup, is stored in ROM 110. 

The personal computer 102 further includes a hard disk drive 116, a magnetic disk 
drive 118, e.g., to read from or write to a removable disk 120, and an optical disk drive 122, 
e.g., for reading a CD-ROM disk 124 or to read from or write to other optical media. The 
hard disk drive 1 16, magnetic disk drive 118, and optical disk drive 122 are connected to the 

15 system bus 108 by a hard disk drive interface 126, a magnetic disk drive interface 128, and 
an optical drive interface 130, respectively. The drives and their associated computer- 
readable media provide nonvolatile storage for the personal computer 102. Although the 
description of computer-readable media above refers to a hard disk, a removable magnetic 
disk, and a CD-ROM disk, it should be appreciated by those skilled in the art that other types 

20 of media that are readable by a computer, including magnetic cassettes, flash memory cards, 
digital video disks, Bernoulli cartridges, ZIP disks, and the like, may also be used in the 
exemplary operating envirormient. 

A number of program modules may be stored in the drives and RAM 1 12, including 
an operating system 132, one or more application programs 134, other program modules 136, 

25 and program data 138. A user may enter commands and information into the personal 
computer 102 through input devices such as a keyboard 140 or a mouse 142. Other input 
devices (not shown) may include a microphone, touch pad, joystick, game pad, satellite dish, 
scanner, or the like. These and other input devices are often connected to the processing 
unit 104 through a user input interface 144 that is coupled to the system bus, but may be 
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connected by other interfaces (not shown), such as a game port or a universal serial bus 
(USB). 

A display device 158 is also connected to the system bus 108 via a display subsystem 
that typically includes a graphics display interface 156 and a code module, sometimes 
5 referred to as a display driver, to interface with the graphics display interface. While 
illustrated as a stand-alone device, the display device 158 could be integrated into the 
housing of the personal computer 102. Furthermore, in other computing systems suitable for 
implementing the invention, such as a tablet computer, the display could be overlaid with a 
touch-screen. In addition to the elements illustrated in FIGURE 1, personal computers also 

10 typically include other peripheral output devices (not shown), such as speakers or printers. 

The personal computer 102 may operate in a networked environment using logical 
connections to one or more remote computers, such as a remote computer 146. The remote 
computer 146 may be a server, a router, a peer device, or other common network node, and 
typically includes many or all of the elements described relative to the personal 

15 computer 102. The logical connections depicted in FIGURE 1 include a local area network 
(LAN) 148 and a wide area network (WAN) 150. Such networking environments are 
commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. It 
should be appreciated that the connections between one or more remote computers in the 
LAN 148 or WAN 150 may be wired or wireless connections, or a combination thereof 

20 When used in a LAN networking environment, the personal computer 102 is 

connected to the LAN 148 through a network interface 152. When used in a WAN 
networking environment, the personal computer 102 typically includes a modem 154 or other 
means for establishing communications over the WAN 150, such as the Internet. The 
modem 154, which may be internal or external, is connected to the system bus 108 via the 

25 user input interface 144. In a networked environment, program modules depicted relative to 
the personal computer 102, or portions thereof, may be stored in the remote memory storage 
device. It will be appreciated that the network connections shown are exemplary and other 
means of establishing a communication link between the computers may be used. In 
addition, the LAN 148 and WAN 150 may be used as a source of nonvolatile storage for the 

30 system. 
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While aspects of the present invention may be implemented on a single computer, 
such as the computer 102 described above, software applications can be quite large, requiring 
substantial amounts of storage. Accordingly, the present invention may be beneficially 
operated in a networked environment where multiple software application builds are 
5 advantageously stored on multiple devices. FIGURE 2 is a block diagram illustrating 
components of an exemplary networked environment 200 for implementing aspects of the 
present invention. 

As shown in FIGURE 2, the exemplary networked environment 200 includes a target 
computer 102, such as the computer described above in regard to FIGURE 1. It is from the 

10 target computer 102 that a software application build is requested. The target computer 102 
is connected to a build master 202 via a network 206, such as the Internet. As will be 
described in greater detail below, the build master 202 responds with information to the 
target computer 102, including where the target computer can obtain the requested build. 
This information is stored by the build master 202 as build data 204. While the build 

15 data 204 is shown as separate fi-om the build master 202, it is for illustration purposes only, 
and should not be construed as limiting upon the present invention. In an alternative 
embodiment, the build master 202 stores and accesses the build data 204 internally. 

The exemplary networked environment 200 also includes one or more build servers, 
such as build server A 208 and build server B 210, connected via the network 206. Each 

20 build server, such as build server A 208 or build server B 210, stores a particular build of a 
software application. For instance, build server A 208 may store a student edition of the 
sought for software application, while build server B 210 may store a profession edition of 
the software. It should be noted that for purposes of the present invention, the format in 
which the build servers store the software application is unimportant. For example, the 

25 configuration servers may store the software application builds as a body of installation files. 
Alternatively, the build servers may store the software application builds as installed images, 
which may then be duplicated to other computers including the target computer 102, using 
techniques well known in the art. Accordingly, the present invention should not be construed 
as limited to storing the software application builds in any particular format. 
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According to one embodiment of the present invention, the build master 202 and 
each build server are directly accessible to, and addressable by, the target computer 102. It 
should be noted that while FIGURE 2, as well as subsequent figures, illustrates that the build 
master 202 and the build servers are separate devices, it is for illustration purposes, and 
5 should not be construed as limiting upon the present invention. Alternatively, the build 
master 202 and the build servers may be logical devices all located on one or more 
computers connected to the network 206. However, if any of the build master 202 or the 
build servers are logical devices, they should still be individually and directly addressable 
from the target computer 102. According to one exemplary embodiment, by associating port 

10 numbers to a particular software build, a single networked computer storing multiple 
software builds can pose as multiple logical build servers, as well as the build master 202. 

In order to better understand the interaction between the identified components of the 
present invention, FIGURE 3 is a block diagram illustrating the exemplary exchange of 
information between a target computer and components of the present invention for 

15 deploying multiple software application builds to the target computer. Beginning with the 
target computer 102, a build request is sent from the target computer to the build master 202, 
as indicated by arrow 301 . The build request identifies which, of all of the available software 
build, is sought. For example, the build request may identify to the build master 202 that a 
developer build of a particular software application is sought. The request also includes 

20 information identifying the requesting party, which is used for authentication purposes. The 
request may further include other information, some of which may provide additional 
installation/deployment options, such as default settings, installation directories, and the like. 
Some of this information may be applicable to all builds of a software application, whereas 
other information may be specific to a particular build. However, for purposes of the present 

25 invention, the additional information accompanying the request does not distinguish one 
software build from another. 

Upon receiving the build request, the build master 202 determines whether the 
requesting party is authorized to make such a request. Thus, the present invention may be 
used to track and regulate the distribution of software builds. Accordingly, if the request is 

30 not an authorized request, an error is returned and the requesting party on the target 
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computer 102 is denied access to the requested build. However, if the request is authorized, 
the build master 202 identifies, according to the build data 204, which build server stores the 
requested build. After determining which build server has the requested build, the build 
master 202 returns the network location of the identified build server, as indicated by 
5 arrow 303, Additionally, the build master 202 also responds with other request data that the 
identified build server may use to validate that the build request is authorized, prior to 
releasing the requested build to the target computer 102. This request data may come in the 
form of a token, possibly encrypted, that the build server will use to validate the request. 
However, the present invention is not so limited. Other information, reflecting the 

10 configuration switches in the request to the build master, may also be included in the 
response from the build master 202. 

As previously mentioned, each build server is directly accessible to the target 
computer 102. Thus, the target computer may already know the location of the build server 
that stores the requested build. However, according to aspects of the present invention, each 

15 build server releases the requested build only when the requesting party presents valid 
request data obtained fi-om the build master 202, as described above. Accordingly, in order 
to ensure that each access to the requested build is authorized, the request data typically 
contains information to control such access. The request data may include unique identifies 
that may only be used a single time, or timed tokens that lapse after a certain amount of time. 

20 It should be xmderstood that these examples are illustrative, and should not be construed as 
limiting upon the present invention. Those skilled in the art will recognize any number of 
mechanisms may be employed to authenticate and track the access to a particular software 
build. 

After receiving the address, or network location, of the build server storing the 
25 requested build, and the request data that enables the requesting party to obtain the requested 
build, the target computer 102 forwards the request data to the identified build server, as 
indicated by arrow 305. Thus, as illustrated in FIGURE 3, the target computer 102 forwards 
the request data to Build Server B 210. Upon receiving the request data, the identified build 
server, such as Build Server B 210, validates the request data to determine whether the 
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request is authorized, and if it is, returns the requested build to the target computer 102, as 
indicated by arrow 307. 

There are many situations where it is not advantageous to expose a target computer to 
the network 204 where the build servers may be found. Securing sensitive/confidential 
5 computers and/or data, virus protection, and the like, often mandate that a target 
computer 102 not be exposed to an external network, or in other words, not be able to 
directly access either the build master 202, or certain build servers. Accordingly, in order to 
facilitate the deployment of multiple software application builds to a secured target 
computer, an altemative, modified configuration may be used. 

10 FIGURE 4 is a block diagram illustrating components of an alternatively configured 

environment 400, and the altemative exchange of information between a target computer 102 
and components in the alternatively configured environment for deploying multiple software 
application builds to the target computer. As will be seen in the description that follows, the 
alternatively configured environment 400 is well suited for deploying muhiple software 

15 application builds to a target computer residing within a secured, or closed, network, where 
the network has very particular and specific openings/gateways to external networks. 
Additionally, because the exchange between a target computer and a local build master is the 
same as between a target computer and a build master and build servers, the altematively 
configured environment 400 can be used in distributed and/or hierarchical fashions to 

20 distribute processing loads among multiple build masters. 

As shown in FIGURE 4, the altematively configured environment may include a 
secure networked area 402, including the target computer 102 and a local build master 404. 
The local build master 404, in addition to other duties described below, fiinctions as the 
access point to the external network 206 (not shown in FIGURE 4) for those devices within 

25 the secure networked area 402. The local build master 404 is also connected to local build 
data 406 and local build cache 408. To the target computer 102, the local build master 
behaves like the build master 202 described above, and, in the case of secure networks, may 
also pose as build servers to the target computer. Thus, as with the build master 202 
described above, the separation of the local build data 406 and local build cache 408 from the 
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local build master 404 is for illustration purposes only, and should not be construed as 
limiting upon the present invention. 

As shown in FIGURE 4, the exemplary alternative configuration 400 also includes a 
build master 202 and build servers, such as build server A 208 and build server B 210, as 
5 described above. However, in contrast to being directly accessible to the target 
computer 102, the build master 202 and build servers are, in this configuration, only directly 
accessible to the local build master 404. The alternative configuration 400 further includes 
the build data 204 as described above. 

For the requesting party on the target computer 102, gaining access to the requested 

10 build is performed in the same manner as described above. Because the local build 
server 404 can function as both a build master as well as a build server, all requests are 
transmitted to/through the local build server 404. A greater description of the entire 
exchange of information between components in this alternatively configured 
environment 400 follows, 

15 To get access to a particular software build in this altemative configuration 400, a 

requesting party, from the target computer 102, transmits a request for the particular build to 
the local build master 404, as illustrated by arrow 401. This request is of the same form, and 
includes the same request information, as the request described above in regard to 
FIGURES. According to one embodiment, the local build master 404 inspects the 

20 information in the request to determine first whether it is valid, i.e., whether the request is 
authorized. If the request is an authorized request, the local build master 404 determines 
whether the requested build is locally cached. If so, no message is forwarded to the build 
master 202. Instead, the local build master 404 generates the request data for obtaining the 
requested software build, and returns the request data to the target computer 102, as indicated 

25 by arrow 407. 

If the requested build is not cached locally, the local build master 404 
submits/forwards the request to the build master 202, as indicated by arrow 403. In yet an 
altemative embodiment, rather than authenticate the request, the local build master 404 
automatically forwards the request from the target computer 102 to the build master 202, as 
30 indicated by arrow 403. As described above, the build master 202 then authenticates the 
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request and if authorized, returns request data back to the local build master 404, as indicated 
by arrow 405. Because the local build master may be the only gateway outside of a secure 
network 402, upon received the request data from the build master 202, which, as previously 
discussed, includes information that identifies the location of the build server storing the 
5 requested software build, the local build master modifies the request data, such that the target 
computer 102 submits the request for the software build to the local build master. The local 
build master 404 then returns the request data to the target computer, as indicated by 
arrow 407. 

10 After receiving the request data from the local build master 404, the target 

computer 102 submits the request with the request data to the local build master, which is 
posing as a build server, as indicated by arrow 409. The local build master 404 examines the 
request and request data, and if it is now locally cached, submits the request and request data 
to the build server storing the requested build, such as build server B 210, as indicated by 

15 arrow 411. Similar to that described above in regard to FIGURE 3, the build server 
authenticates that the request is an authorized request, and if so, returns the requested build to 
the local build master 404, as indicated by arrow 413. 

After receiving the requested build from a build server, the local build master 404 
may optionally store the requested build in its build cache 408, as indicated by arrow 415. 

20 The local build master 404 then forwards the requested build onto the target computer 102, 
as indicated by arrow 419. As previously mentioned, the local build master 404 may already 
have the requested build locally cached. Thus, when the requested build is locally cached, 
instead of obtaining the requested software build from a build server, the local build 
master 404 simply retrieves the requested build from the build cache 408, as indicated by 

25 arrow 417, and returns it to the target computer 1 02. 

FIGURE 5 is a flow diagram illustrating an exemplary method 500 for deploying one 
of multiple software application builds to a target computer in accordance with the present 
invention. Beginning at block 502, a build request identifying the sought for build is sent 
30 from the target computer 1 02 to the build master 202. 
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At block 504, the build master 202 authenticates the request to determine whether the 
requesting party is authorized to access the sought for build. At decision block 506, a 
determination is made as to whether the request is authorized. If the request is not 
authorized, at block 508 an error is reported to the requesting party, and the routine 500 

5 terminates. 

If, at decision block 506, the request is authorized, then at block 510, the build 
master 202 identifies a build server that stores the sought for software build. At block 512, 
the information identifying the build server with the sought for software build, and request 
data to be presented to the identified build server, are retumed to the target computer 102. 

10 At block 514, the target computer 102 transmits a request with the request data 

obtained from the build master 202, to the identified build server. 

At block 516, the build server authenticates the request data for determining whether 
the request for the sought for build is authorized, as described above in regard to FIGURE 3. 
At decision block 5 1 8, a determination is made as to whether the request is authorized. If the 

15 request is not authorized, at block 508 an error is reported to the requesting party, and the 
routine 500 terminates. 

If, at decision block 5 1 8, the request is authorized, then at block 520 the sought for 
build is retumed to the target computer 102. At block 522, the sought for build is installed 
on the target computer 102. Thereafter, the routine 500 terminates. 

20 FIGURES 6A and 6B are a flow diagram illustrating an altemative exemplary 

method for deploying one of multiple software application builds to the target computer 
using the secure networked configuration 400 described above in regard to FIGURE 4. 
Beginning at block 602, a build request identifying the sought for build is sent firom the 
target computer 102 to the local build master 404. 

25 At block 604, the local build master 404 authenticates the request to determine 

whether the requesting party is authorized to access the sought for build. At decision 
block 606, a determination is made as to whether the request is authorized. If the request is 
not authorized, at block 608 an error is reported to the requesting party, and the routine 600 
terminates. 
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If the request is authorized, at decision block 610, another determination is made as to 
whether the sought for build is locally cached to the local build master 404. If the sought for 
build is not locally cached, at block 624 (FIGURE 6B), the local build master 404 forwards 
the request to the build master 202. 
5 At block 626, the build master 202 authenticates the request to determine whether the 

requesting party is authorized to access the sought for build. At decision block 628, a 
determination is made as to whether the request is authorized. If the request is not 
authorized, at block 608 (FIGURE 6A) an error is reported to the requesting party, and the 
routine 600 terminates. Alternatively, if the request is authorized, at block 630, the build 

10 master 202 identifies the build server according to the request. At block 632, a response is 
returned to the local build master 404. 

At block 634, the local build master 404 obtains the sought for build from the 
identified build server using the information returned from the build master 202. At 
block 636, the local build master locally caches the sought for build. Thereafter, the routine 

15 retums again to decision block 610 (FIGURE 6 A), where a determination is made as to 
whether the sought for build is locally cached to the local build master 404 (which at this 
point it should be). If the sought for build is locally cached, at block 612, information 
identifying the location of the sought for build along with request data to obtain the build is 
returned to the target computer 102. In this instance, the location will be the local build 

20 master 404. However, as previously mentioned, a build server can be a logical device. 
Hence, in this instance, the local build master 404 can pose as a build server to the target 
computer 102, and receive the request and request data. 

At block 614, the target computer 102 transmits the request with the request data 
obtained from the local build master 404, to the identified, logical build server, i.e., back to 

25 the local build master. 

At block 616, the local build master 404, still posing as a build server, authenticates 
the request for determining whether the request is authorized. At decision block 618, the 
determination is made as to whether the request is authorized. If it is not authorized, at 
block 608, an error is reporting to the requesting party at the target computer 102, and the 

30 routine 600 terminates. Alternatively, if the request is authorized, at block 620, the sought 
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for build is returned to the target computer. At block 622, the build is then installed on the 
computer, and the routine 600 terminates. 

While the preferred embodiment of the invention has been illustrated and described, 
it will be appreciated that various changes can be made therein without departing from the 
5 spirit and scope of the invention. 
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